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REMARKS /ARGUMENTS 

In view of the foregoing amendments and the 
following remarks, the applicant respectfully submits 
that the pending claims are not rendered obvious under 35 
U.S*C. § 103. Accordingly, it is believed that :his 
application is in condition for allowance. If, lowever, 
the Examiner believes that there are any unresol ved 
Issues, or believes that some or all of the clairas are 
not in condition for allowance , the applicant 
respectfully requests that the Examiner contact Ae 
undersigned to schedule a telephone Examiner Interview 
before any further actions on the merits . 

The applicant will now address each of the .ssues 
raised in the outstanding Office Action. 

Objections 

Claims 16, 17, 42 and 43 are objected to as being 
dependent upon a rejected base claim, but would be 
allowable if rewritten in independent form including all 
of the limitations of the base claim and any intervening 
claims. Claims 16 and 17 depend, indirectly, from claim 
12, and claims 42 and 43 depend, indirectly, fron claim 
38. Since, however, base claims 12 and 38, as anended, 
are allowable over the cited art for the reasons 
discussed below, these claims have not been rewritten in 
independent form at this time. 
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Rejections under 35 U.S.C. § 103 



Claims 1-15, 19-41, 45-50 and 52 stand rejected 



under 35 U.S.C. § 103(a) as being unpatentable ever David 
Comer, Internetworking with TCP/IP , (2000) Prenl ice Hall 
(pub) ("the Comer book") and further in view of Sandick, 
et al., "Internet-Draft Fast Liveness Protocol,' 
(February 2000) ("the Sandick paper"). The applicant 
respectfully requests that the Examiner reconsic.er and 
withdraw this ground of rejection in view of the 
following. 

Before addressing at least some of the pate ntable 
features of various claims, exemplary embodiment s 
consistent with the claimed invention are first 
introduced. Exemplary embodiments consistent with the 
claimed invention may be used to provide a "live ness 
detection mechanism" for quickly detecting a dov n routing- 
protocol used by nodes on a network by exchanging 
messages which include aggregated protocol and/ar 
forwarding liveness ("APFL") status information with 
neighboring nodes. (See paragraphs [0012], [00^6] and 
[0086] of the present application.) The APFL status 
information may contain, for example, the status of the 
at least two different kinds of routing protocol s used by 
the nodes. The specification describes the di£ rerent 
kinds o£ routing* protocols which can be aggregat ed and 
reported on as including; 
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Bit position 



Protocol 
BGP 



IS-IS 



OSPF v2 
OSPF v3 
RIP v1/v2 
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5 RIP NG 

6 PIM 

7 DVMRP 

8 LDP 

9 RSVP 

10 LMP 



(See paragraphs [0012] and [0041] of the present 
application.) Note that Border Gateway Protocol (BGP) is 
just one of the many different kinds of routing protocols 
that may be included in the aggregated message. 

This feature provides several advantages. ^s the 
specification states : 

hello messages [in conventional 
liveness detection mechanisms] often 
carry more than just liveness 
information, and can therefore be 
fairly large and require non trivial 
computational effort to process. 
Consequently, running fast liveness 
detection between a pair of neighbor 
nodes, each running multiple protocols , 
can be expensive in terms of 
communications and computational 
resources required to communicate and 
process the frequent, lengthy messages 
for liveness detection. [Emphasis 
added. ] 

(Paragraph [0009] of the present application) Tnese 
conventional liveness detection mechanisms require 
separate hello messages for each different protocol run 
on the node. The ability to send aggregated protocol 
status information of multiple protocols overcomes the 
foregoing problem as follows: 

By providing a small number of 
bits per protocol, which relay a simple 
set of information (such as up, down, 
not reporting, restarting, etc), a 
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compact, simple message may be used f o : 
conveying- liveness related. Information. 
Since the messages are small and can 
aggregate information from more than 
one protocol, they can be sent 
frequently. [Emphasis added.] 

(Paragraph [0086] of the present application) As can be 
appreciated from the foregoing, the status information of 
at least two different kinds of routing protocol ?, and 
the at least two indicators identifying a differ mt one 
of the at least two different kinds of routing protocols, 
can be aggregated into a single message wherein >ach of 
the state of the protocols being run may be set, for 
example, to up, down, not reporting or restarting. 

Having introduced some exemplary embodiment 5 
consistent with the claimed invention, at least some 
patentable features of the claimed invention are now 
discussed. 

Independent claims 1 and 27, as amended, ar»; not 
rendered obvious by the Comer book and the Sandi-:k paper 
because the cited references, either taken alone or in 
combination, neither teach, nor make obvious, conposing 
an aggregated message including at least two indicators, 
each indicator identifying a different one of th<» at 
least two different kindn of routing protocols and the 
corresponding status information from each of th** at 
least two different kinds of routing- protocols a;t data 
within the aggregated message. In rejecting independent 
claims 1 and 27, the Examiner contends that the Comer 
book teaches: 

a) accepting, using the node, 
status information from at least two 
different protocols (Comer; 15.10 BGP 
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Functionality and Message Types and 
15.16 BGP KEEPALIVE Message, discloses 
determining at a first node status 
information for both BGP and TCP 
protocols) ; 

b) composing, using the node, an 
aggregated message including the statu? 
information from the at least two 
different protocols [ . . . ] (Comer; 
Figure 15.10 BGP Functionality and 
Message Types and 15.16 BGP KEEPALIVE 
Message, discloses composing an 
aggregated keepalive message including 
the status information) / and 

c) sending, using the node, the 
aggregated message towards a neighbor 
node (Comer; 15.10 BGP Functionality 
and Message Types and 15.16 BGP 
KEEPALIVE Message, discloses sending 
the keepalive message to neighbor 
second node). [Emphasis added.] 

(See Paper No. 20090423, page 3.) Thus, the Exaniner 
contends- that the Comer book "discloses determining at a 
first node status information for both BGP and TDP 
protocols" and "discloses composing an aggregate! 
keepalive message including the status information." 
However, the KEEPALIVE message described in the Corner 
book "consists of a standard message header with no 
additional data. [Emphasis added.]" (Section 15.16 of 
the Comer book) Furthermore, a BGP "standard message 
header" includes only three fields: (1) a MARKED field 

(which contains a value that both sides agree to use to 
mark the beginning of a message), (2) a LENGTH field 

(which specifies the total message length measured in 
octets), and (3) a TYPE field (which contains a L-octet 
field containing the type of message, e.g., a KE 2PALIVE 
message type). (See sections 15.10, 15.11 and 13.16 of 
the Comer book.) None of the fields include the statuses 
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of at least two different routing protocols . Al ihough 
the receipt of a KEEPALIVE message in and of itself may 
indicate the connectivity of a peer node, in no '/ay does 
the KEEPALIVE message described in the Comer boo : include 
status information from at least two different routing 
protocols as data within the message. 

Furthermore, it appears that since BGP uses or runs 
on the Tranmission Control Protocol (TCP) for transport 
(i.e., as its transport protocol), the Examiner 1 s 
position is that a single KEEPALIVE message may .ndicate 
the status information of both the BGP and TCP protocols. 
However, while BGP is a kind of routing protocol TCP Is 
a transport protocol used by BGP for transmission TCP 
Is not a routing protocol. The differences between 
routing protocols (such as the ones listed above and TCP 
are well understood by those skilled in the art. 

In order to clarify these differences, independent 
claims 1 and 27 have been amended to recite that the 
status information pertains to at least two different 
kinds of routing s protocols (e.g., at least two different 
routing protocols from the list of protocols discussed 
above and included in paragraph [0041] of the present 
application) . 

In addition, claims 1 and 27 have been amended to 
clarify that the aggregated message Includes (A) two 
Indicators , each Indicator Identifying a different one of 
the at least two different kinds of routing protocols and 
(B) the corresponding status Information from ea zh of the 
at least two different kinds of routing protocols as data 
within the aggregated message. These amendments are 
supported, for example, by element 424 of Figure 4 and 
paragraphs [0012] and [0041] of the present application. 
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Thus, in view of the foregoing amendments aid 
remarks, the Comer book does not teach, or make obvious / 
composing an aggregated message including at least two 
indicators, each indicator identifying a different one of 
the at least two different kinds of routing protocols and 
the corresponding status information from each of the at 
least two different kinds of routing protocols as data 
within the aggregated message. 

Furthermore, the purported teachings of the Sandick 
paper do not compensate for the deficiencies of the Comer 
book discussed above. Specifically, the Sandick paper 
includes a "list of neighbor interfaces that the 
transmitting device has heard from." (Section 4.2 of the 
Sandick paper.) The described list is "[a] list of all 
source IP. addresses of all FLIP Advertisements tnat have 
been heard on this interface". (Section B.l of the 
Sandick paper.) This list of neighbor interfaces that 
the transmitting" device has heard, from does not indicate 
the status of the at least two different kinds of routing 
protocols being used by the neighboring nodes. father, 
in the Sandick paper, a node receiving a status nessage 
from a neighbor node can only infer that status :>f its 
own interface with the neighbor node (and, thus, the 
status of the protocol being used by that interface) . 
Specifically, the Sandick paper provides: 

When a device receives a FLIP 
Advertisement from a neighbor, it lists 
the neighbor interface in its own FLIP 
advertisements for that interface. If 
a device receives an advertisement 
containing its own interface in one of 
the neighbor fields and it has listed 
that neighbor in its own advertisement , 
a FLIP adjacency is established. If an 
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advertisement containing the receiving 
device interface has not been received 
from a neighbor in 

FLIPAdvertismentDeadlnterval seconds, 
then that neighbor is removed from 
subsequent advertisements (for that 
interface) and the adjacency is 
considered down. 

(Section 4.5 of the Sandick paper.) As can be 
appreciated from the foregoing, even though a FLCP 
Advertisement message may include a list of all source IP 
addresses of all nodes that the transmitting nod? has 
heard from, the receiver node can only Infer the status 
of the protocol being used by Its Interface with the 
sending node. That is, the inclusion of source CP 
addresses in the FLIP Advertisement does not provide the 
status of the source nodes. Thus, the Sandick pa )er 
neither teaches, nor makes obvious, accepting stitus 
information of at least two different kinds of routing 
protocols (e.g., which Indicates whether the at least two 
protocols are up, down, not responding", or restarting) 
and composing an aggregated message including ttv* status 
information of the at least two different kinds of 
routing protocols as data within the aggregated nessage. 

Furthermore, the Sandick paper is clearly not 
concerned with the statuses of at least two different 
kinds of routing protocols. 

. Thus, independent claims 1 and 27, as amended, are 
not rendered obvious by the Comer book and Sandick paper 
for at least the foregoing reasons. 

Independent claims 12, 19, 22, 38 and 45, hc.ve been 
similarly amended and are similarly not rendered obvious 
by the Comer book and Sandick paper. 
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Since claims 2-11, 48, 49 and 50 directly o: 
indirectly depend from claim 1, since claims 13- L5 and 52 
directly or indirectly depend from claim 12, sin ;e claims 
20 and 21 depend from claim 19, since claims 23- 16 
directly or indirectly depend from claim 22, sin :e claims 
28-37 directly or indirectly depend from claim 2?, since 
claims 39-41 directly or indirectly depend from :laim 38, 
and since claims 46 and 47 directly or indirectl r depend 
from claim 45, these claims are similarly not rendered 
obvious by the Comer book and Sandick paper. 

Claims 18 and 44 stand rejected under 35 U.:;.C. 
§ 103(a) as being unpatentable over the Comer book and 
the Sandick paper, further in view of U.S. Patent. No. 
5,349,642 ("the Kingdon patent"). The applicant 
respectfully requests that the Examiner reconsider and 
withdraw this ground of rejection in view of the - 
following . 

Claims 18 and 44 depend from claims 12 and 18, 
respectively. Since the purported teachings of 1 he 
Kingdon patent do not compensate for the deficiencies of 
the Comer book and Sandick paper with respect to claims 
12 and 38, as amended (discussed above), these c2 aims are 
not rendered obvious by the Comber book, the Sane ick 
paper and the Kingdon patent, regardless of the purported 
teachings of the Kingdon patent, and regardless cf the 
presence or absence of an obvious reason to combine these 
references as proposed by the Examiner. 

Claims 51 and 53 stand rejected under 35 U.S.C. 
§ 103(a) as being unpatentable over the Comer bock and 
the Sandick paper, further in view of U.S. Patent No. 
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7,362,700 ("the Frick patent"). The applicant 
respectfully requests that the Examiner reconsider and 
withdraw this ground of rejection in view of the 
following . 

Claims 51 and 53 depend from claims 1 and 11, 
respectively. Since the purported teachings of :he Frick 
patent do not compensate for the deficiencies of the 
Comer book and Sandick paper with respect to claims 1 and 
12, as amended (discussed above) , these claims are not 
rendered obvious by the Comer book, the Sandick )aper and 
the Frick patent, regardless of the purported te ichings 
of the Frick patent, and regardless of the prese ice or 
absence of an obvious reason to combine these re zerences 
as proposed by the Examiner . 

Claim amendments 

In addition to the claim amendments discussed above, 
claim 49 was amended to correct a typographical '>rror. 

New Claims 

New claims 54 and 55 depend from independent claims 
1 and 12, respectively. These claims are supported by 
original claims 11 and 15 and paragraph [0041] of the 
present application . 

Conclusion 

In view of the foregoing amendments and remarks, the 
applicant respectfully submits that the pending claims 
are in condition for allowance. Accordingly, th<; 
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applicant requests that the Examiner pass this 
application to issue. 

Any arguments made in this amendment pertai i only to 
the specific aspects of the invention claimed. Any claim 
amendments or cancellations, and any arguments, ire made 
without prejudice to, or disclaimer o£, the applicant's 
right to seek patent protection of any unclaimed (e.g., 
narrower, broader, different) subject matter, su :h as by 
way of a continuation or divisional patent appli :ation 
for example* 

Since the applicant's remarks, amendments, ind/or 
filings with respect to the Examiner's objections and/or 
rejections are sufficient to overcome these objections 
and/or rejections, the applicant's silence as to 
assertions by the Examiner in the Office Action and/or to 
certain facts or conclusions that may be implied by 
objections and/or rejections in the Office Action (such 
as, for example, whether a reference constitutes prior 
art, whether references have been properly combined or 
modified, whether dependent claims are separately 
patentable, etc.) is not a concession by the applicant 
that such assertions and/or implications are accurate, 
and that all requirements for an objection and/o:: a 
rejection have been met. Thus, the applicant reserves 
the right to analyze and dispute any such assertions and 
implications in the future. 

Respectfully submitted, 



July 28, 2009 




Reg. No. 60,441 
Tel.: (732) 936-1400 
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